EC/CRMの自社サービス「prismatix」の開発チームのマネージャーになってからやったことl連発

EC/CRMの自社サービス「prismatix」の開発チームのマネージャーになってからやったことl連発

prismatix事業部の開発チームのマネージャーになって、最初に取り組んだ施策や活動を順不同で紹介します。
Clock Icon2022.04.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

おさらい

1月にprismatix開発プロジェクトマネージャーから開発チームのマネージャーになりました。

この記事では、マネージャーになってから取り組んできたことを、順不同で紹介します。

やったこと l 連発 (順不同)

1. 所信表明演説

2. モブプログラミング講座実施

3. モブプログラミングの導入

  • モブプロ講座の後、1つのチームでモブプロ導入
    • 1日2時間+2時間くらい全員で集まるのを始めてみた
  • このままの形では定着しなかった
    • 開発スピード鈍化とストレス増加が発生
      • 開発スピードについては織り込み済みだった
      • ストレス増加は想定以上に大きかった
  • チームでふりかえってやり方を徐々に変えてみた
    • 探索的な作業で有効そうという意見がでた
      • 方針検討やレビューやログ調査など
    • チームで必要に応じて随時行う形になっていった

4. リリースに向けた開発プロセス改善

  • 従来は1週ごとに「その日の状態そのまま」で、機械的にリリースしていた
  • さらに顧客開発環境に週次で最新版をデプロイするプロセスになっていた
    • 結果、顧客開発環境にいきなり後方互換性を破壊するような機能がデプロイされることが稀に起きていた
  • これを防ぐため、「マイルストーン」を定めてそこに到達したらリリースする流れにした
    • 生煮えの状態ではリリースせず、ちゃんと準備ができてから、次のリリースタイミングでリリースする
  • 一緒に顧客開発環境への定期デプロイも停止
    • そもそも顧客が求めていることではなかった
      • そもそも開発中の機能を即座に使いたいという動機はない
        • 機能がちゃんと使える状態で提供される方が嬉しい

5. チーム稼働状況の可視化

  • 前回の記事で書いたとおり、各チームの「前向きな活動」、「運用に必要な活動」、「非生産的な活動」、「刃を研ぐ活動」の稼働割合を収集し始めた
  • その集めた稼働割合を元にグラフで状況を可視化した チームごとの稼働割合グラフ
  • こんなことが見て取れそう
    • 全体的に「前向きな活動」を徐々に増やせてきている
      • チームの活動によって他の時間を減らせているのかも?
    • 「運用に必要な活動」には波があるが、特に「注文・決済」、「検索」チームでその割合が多め
      • チームへの問い合わせやアラート対応の割合が多いのかも?
    • 「非生産的な活動」は全体としては少ないが、発生すると稼働を多く持っていかれてしまう
      • チームとしての動きが止まらないような体制が必要かも?
  • あくまで「かも?」までしかわからない
    • この先については個別にヒアリングしたりなどが必要
  • とはいえ、チームの改善に向けての足がかりにできそう

6. フリーランスを対象とした増員

  • 開発チームへの負荷が高い状況をなんとかするため、余力を作る必要がある
  • そのためにある程度長期的にコミットしてもらう前提でフリーランスを募集
    • もちろん社員の採用も並行で進める
  • 負荷が高い注文・決済チーム、比較的期限が近い要望がたくさんある保守開発チームをターゲットに増員
    • ただ、いきなり増やすとそれはそれで負荷になるので少しずつ

7. Pull Requestテンプレートの小さな改善

  • 元々Pull Request(PR)のテンプレートをそれなりに作り込んでいた
  • そのうち下記の変更を行った
    • リリースノート
      • PRの変更をフロント開発者向けに説明するためのリリースノートを書くところ
      • そこに開発ドキュメントへのリンクを記載するための項目を追加
        • 変更がどの機能に影響しているのかすぐに分かるようにするため
    • デプロイ担当者への依頼事項
      • Kibanチーム(運用作業を行うチーム)向けの注意事項を書くところ
      • 特定のスクリプトを使うケースで、そのファイル名を明記するように
        • 運用作業の中で、毎回PRの内容から使うファイルを推測していたのをやめるため

8. 開発エンジニアの増員に向けてES部との連携強化

  • クラスメソッドでは人事をES(エンプロイーサクセス)部が担当している
  • 開発エンジニアの採用を強化したいとまずは意思を連携
    • その後、どんな動きができるか、できそうかを相談
  • 結果、募集枠を増やしたり、採用プラットフォームを通じたスカウト活動につなげたりしている

9. チーム体制変更

  • リフォームの匠 チームのメンバーから何人かが、新規プロダクト開発の活動にピボットした
  • 同時に Kibanチームからも SRE を作る流れがあった
  • この流れを合わせて一部チームを再編した
    • Kibanチームマネージャーとも頻繁に意見交換を行った
  • 再編されたチーム
    • SREチーム
      • DevOpsを体現するスペシャリスト
        • 将来的にはDevチームとKibanチームを統合するための媒体とする
      • メンバー構成
        • Kibanチーム内から3名
        • リフォームの匠チームから1名
    • イネーブリングチーム
      • 品質や開発力を高めるためのファシリテーター
      • メンバー構成
        • 匠チームから2名
  • 部内にも「チームトポロジー」を引き合いに出しつつ、体制変更の狙いを説明

10. 募集ポジション追加

11. ファシリテーション塾を実施

  • 前述のイネーブリングチームはファシリテーションスキルが不可欠
    • チームメンバーとはコラボレーションではなくファシリテーションでコミュニケーションするのが基本のため
  • メンバーのファシリテーション力を高めたかった
  • 内製化支援グループgaoryu さんにファシリテーション塾を依頼
    • 私とイネーブリングチームメンバーが参加
  • これまでに3回開催
    • ファシリテーションとは?
      • 目的に対してチームを「促進」する行為がファシリテーション
        • 目的に向かうためのゴールを設定して、そちらに向かわせる
        • ふるまいで人を動かす
        • 促進させるための「デザイン」を行う
      • 変化型ファシリテーション: 人の系に対する高速フィードバック制御
        1. 見る
        2. フィードバックを受ける
        3. 感情として感じる ※ここが大事
        4. 感情を切り離して ふるまいを考える
        5. ふるまう
        6. チームが変化する
        7. 最初に戻って繰り返す
    • 場の設計
      • 登場人物と関係性を見る
        • その上で期待をチームに共有して歩み始め、目標に向けて働きかける
    • 提案と相談の違い
      • 物事を依頼すると「提案して欲しい」という意思表明になる
        • 提案されたらレビューすることになる
          • 批評家として見てしまう
      • 物事を相談すると「共に作ろう」という意思表明になる
        • 出てきたものを方向修正しながら一緒に作り上げる活動ができる
          • 「味方」としての関係性になる
      • 「形式知」ができたら、以後「依頼」の形にすれば良い

12. 定期的な 1on1

  • 大体2週に1度の定期的な1on1を実施
  • メンバーの感じていること、状況等を掘り下げて会話
    • プロジェクト進行に関すること以外も
  • 私に対する「話しやすさ」を上げる効果も期待

13. 採用タスク引き継ぎ

  • 前のDevマネージャーの塩谷 が担当していた採用関係の知見を引き継ぎ
  • 説明ドキュメントを作ってもらい共有
    • 募集
    • 書類審査
    • 面接とオファー
    • 会社説明会、など
  • エンジニアリング統括室の田部井(てぃーびー)との相談も
    • 最近の「相場感」を教えてもらう
    • 「採用」という活動の流れを改めて教えてもらう

14. 会社説明会登壇

  • 採用活動引き継ぎの一貫として、クラスメソッドが開催している中途向け会社説明会に登壇
    • 1,2,3,4月の4回
  • 塩谷が使っていた資料を参考にはしつつ、現状に合わせて毎回内容をアップデートしながら実施

15. オープンポジション発表会登壇

  • クラスメソッドには「越境チャレンジ」という部署をまたいで新たなポジションにチャレンジできる制度がある
  • そのための「オープンポジション発表会」にてprismatixとして登壇
    • 会社説明会で登壇している内容をベースに社内向けの味付けをして

16. 「一体感」の深堀り

17. 大規模リリース実施

  • 半期から四半期ごとに実施している「利用推奨バージョン」のリリース作業を行った
    • LTS扱いにすることで、開発・運用負荷を下げる目的のもの
  • リリースに向けた性能試験を実施し、前回の大規模リリースとの比較を実施
    • 差が出た部分について深堀り
  • 性能試験を行う中で出てきた課題を取りまとめ
    • 次回の大規模リリースに向けて取り組む計画中

18. 他部署のスクラムマスターとの交流

  • CX事業本部には案件毎に多くのスクラムマスターが活動している
    • そして、スクラムマスターが週次で集まって雑談する会があった
  • prismatix事業部はスクラムこそ行っていないがアジャイル開発を行っている
  • アジャイル開発の知見や相談などを期待してスクラムマスター雑談会に参加するようにした
    • 結構お悩み相談室みたいなことも起きていて面白い

19. 勤怠管理

  • クラスメソッドでは勤怠管理システムの KING OF TIME(KoT) を利用している
  • 定期的な勤怠の「締め」や勤怠に関する相談などの対応を実施

20. 入場時の作業環境構築ドキュメント刷新

  • エンジニアが入場する際に参考にする環境構築ドキュメントが散在していた
    • Confluenceとesaのようにドキュメントツール自体の分散
    • Dev/Kibanなどチーム別の分散
    • 同一チームでも新旧の手順が混ざっている
  • Kibanチームと相談しエンジニア向け作業環境構築文書を刷新
    • 共通手順を統一
    • チーム別個別手順を分割
      • IDEなどDevチームだけが使うツールはこちらに
    • インストール対象者を明記
    • 関連手順ドキュメントへの導線を整理

21. Devチーム向けITSMツール利用手順レビュー

  • 業務改善チーム が進めるITSMツールのDevチーム向け利用手順ができた
  • Devチームに説明するにあたって気になる部分についてフィードバック
    • ツールの目的や利用ケースなど
  • その利用手順を元に、後日Devチーム向けに説明をして利用開始してもらっている
    • 顧客からの問い合わせのエスカレーションを受ける
    • 顧客本番環境について調査依頼をする

22. 組織紹介ブログエントリ作成

23. 全社新卒研修に参加

  • 2022/4入社の新卒研修をエンジニアリング統括室が取りまとめていた
  • また「ソフトウェアテスト」のコースについてprismatix事業部が担当することになった
    • 「開発プロセス」および「チーム開発」コースを行うCX事業本部のメンバーと担当範囲のすり合わせを実施
    • その後コース設計を行う
    • この後5月に実際に実施する予定

24. リリース予定カレンダー作成

  • リリースに向けた開発プロセス改善 の中で、1スプリントを2週間に変更した
  • リリース日が毎週でなくなり、わかりにくくなった
  • それを解決するため、Googleカレンダーとして「リリース予定カレンダー」を作成して部署に共有した

25. Spring4Shell対応

  • 3月末から4月頭にかけて世間を賑わせた、Springフレームワークのゼロデイ脆弱性「Spring4Shell」に対応した
  • 影響範囲の調査
  • 脆弱性対応
    • 即座に影響はないとはいえ、対応しておいたほうが良いものではある
    • Springプロジェクトの公式情報 に従い、プロダクトに修正を実施
      • メインライン
      • 過去のリリースバージョンのパッチバージョンアップ

26. 採用一次面接

  • 応募者に対して一次面接として部署説明とカルチャーマッチ判断
    • もし採用できた後に配属したいチームリーダーなどのメンバーと一緒に実施
  • 面接官をお願いしたメンバーと事前にすり合わせ
    • 何を期待しているか
    • どのポイントを見るか
    • 書類で気になったポイントはどこか
  • すり合わせた内容を元に面接を実施

27、28、29、……

その他プロジェクト管理や顧客環境で発生したアラート対応についての調整など、いつもの仕事はたくさんやっていました。

まとめ

Devチームのマネージャーになり、当初想定していた通りピープルマネジメントに関する1on1や採用関係の取り組みがやはり多かったですね。とはいえ、チームや開発マネジメントもあまり減ったわけではないので、かなり忙しく動いていた印象です。

ただ、おかげで採用やチームに関する資料やドキュメントなどもだんだんと整ってきたので、少しずつ視点を上げてもっと先を見据えた活動を今後やっていけたらと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.